Adds a fifth enrichment pass to spo_enrich.py: `fields.Selection`
declarations with a statically-resolvable list of 2-tuples emit one
`(odoo:<model>.<field>, selection_value, "<key>")` triple per enum key.

# Shape

`_extract_selection_values(call)` pulls the first element of each 2-tuple
from the Selection list — positional arg 0 OR `selection=` kwarg —
preserving source order, de-duplicating (first occurrence wins).

Skipped (values not statically knowable):
  - `selection='_compute_states'` (compute-method ref, a str)
  - `selection=STATE_CONSTANT` (bare Name)
  - `related=...` / any non-list/tuple selection arg
  - individual entries that aren't 2-tuples

Truth `(0.95, 0.90)` — read straight from the field decorator,
authoritative. Scoped to corpus-declared ObjectTypes (the additive
boundary, same as P1); Selection fields bind to the same `model_names`
as relational fields (`_name`, else `_inherit[0]`, per #525's decision).

# Consumer use

Lets odoo-rs lower a Selection field to
`DEFINE FIELD state … ASSERT $value IN ['draft','posted','cancel']`
— the UPSTREAM_WISHLIST P3 ask. The five-pass enrichment is now:
P1 (target/inverse_name) + P0 (deep reads_field) + P1b (inherits_from)
+ P2 (validation_kind) + P3 (selection_value).

# Corpus regen pending

The shipped corpus does not yet carry selection_value triples —
regenerating requires running the script against a live Odoo source
tree (`/home/user/odoo/addons`), not present on this host. The Rust
loader's predicate-histogram match arm gained `selection_value` so a
future regenerated corpus drops into the harness without code changes.
`parses_all_triples` count assertion stays at 24 579; re-locks the
moment a session with the source re-runs enrichment.

# Files

  spo_enrich.py:
    +`_extract_selection_values` helper, +`SELECTION_VALUE_TRUTH`,
    +`selections` param threaded through `_scan_file` / `build_all_facts`
    / `enrich`, +Selection branch in the field loop, +P3 emission loop,
    +CLI status field.
  test_spo_enrich.py:
    +12 tests (6 extraction edge cases + 3 scan-binding + 3 emission).
  odoo_ontology.rs:
    +doc table row, +histogram match arm for `selection_value`.
  EPIPHANIES.md: prepended E-ODOO-SPO-SELECTION-VALUE.

# Tests

  python3 -m unittest tests.test_spo_enrich : 53/53 OK (was 41)
  cargo test -p lance-graph --lib odoo_ontology : 13/13 OK

…d Core, harvest is subordinate

Repurposes the P3 selection_value work after the operator caught a real
architectural inversion: the wishlist's structural asks (target /
inverse_name / inherits_from / selection_value) are CORE facts, not
behavioural harvest, and belong in the typed `OdooEntity` Core
(`lance-graph-ontology::odoo_blueprint`) — not bolted onto the flat SPO
ndjson by `spo_enrich.py`.

Source-verified: `OdooField.target` ALREADY exists in the Core, so the
`target` harvest pass was re-deriving a fact the Core already held;
`inherits_from` + `selection_value` were genuine Core gaps filled on the
harvest side — the "Core gap → extend the Core deliberately, never hack
the adapter" anti-pattern.

# Why a side-table, not a struct field

`OdooField` has 3 554 literal sites, `OdooEntity` 404, no constructor.
Adding a field to the mega-structs breaks every literal. The
doctrine-correct "extend the Core deliberately" for a literal sea that
size is a TYPED SIDE-TABLE — still Core, still authoritative, beside the
mega-structs instead of inside them.

# What lands

New `odoo_blueprint/structural.rs`:
  - `OdooInherits { model, bases }` — the _inherit/_inherits mixin chain
    (OdooEntityKind records the ORM base class, not the mixin list)
  - `OdooFieldSelection { model, field, values }` — Selection value domain
    (OdooFieldKind::Selection flags it; OdooField never stored the values)
  - Curated `account.move` consts, GROUNDED: INHERITS matches the #527
    corpus (mail_activity_mixin + sequence_mixin); FIELD_SELECTIONS uses
    canonical standard Odoo state/move_type value sets.
  - `project_inherits_from` / `project_selection_value` — Core → SPO
    projection (direction of truth: Core out to SPO, never the reverse).
  - 5 tests incl. a consistency check against the #527 corpus.

# Reframing (anti-self-fulfilling-drift)

So a future session does NOT read the prior work as "add another
spo_enrich predicate":

  - `spo_enrich.py` module-doc gains an ARCHITECTURE NOTE: the structural
    predicates' authoritative home is the typed Core; this file is the
    Extracted-leg BREADTH feeder for the ~322 ObjectTypes the curated
    Core hasn't reached; Curated Core wins on convergence. Behavioural
    predicates (deep reads_field, emitted_by, validation_kind) ARE
    genuine harvest and correctly stay.
  - `EPIPHANIES.md` prepends E-ODOO-CORE-FIRST-STRUCTURAL, which
    explicitly BOUNDS THE FRAMING of the four prior E-ODOO-SPO-* entries
    so the predicate-bolt-on cadence isn't read as the intended
    architecture. Names `virtually_overrides` as a ClassView/Core
    capability — NOT harvest predicate #6.

# Not changed

The selection_value AST reader in spo_enrich.py stays (it's the Extracted
leg's mechanism for breadth) — now correctly subordinate to the Core.
Behavioural harvest is untouched.

# Tests

  cargo test -p lance-graph-ontology --lib structural : 5/5
  python3 -m unittest tests.test_spo_enrich            : 53/53
  cargo test -p lance-graph --lib odoo_ontology        : 13/13 (unchanged)